	The last few days I have been working on more mundane issues, and that
is quite a relief.  After spending so much time on agonized hand-wringing and
hair-pulling, it is nice to be able to concentrate on more obviously
productive endeavors.  I settled many of the problems that were bothering me
about the game and deferred solution of the others while I went back to the
code.
	The code itself has provided some satisfyingly simple challenges.  I'm
sure this comment will offend some people, but I find programming to be a 
pleasant form of near-mindless busywork that is a great relief from the
mind-breaking labors of game design.  Over the last few days I have been 
reworking major elements of the design.  First I had to rework the time system
used in the game, from a player-oriented turn structure to a more objective
form of time.  That was fun.  Let me digress to address the subject.
	There are a number of ways to handle time in any game.  The first and
easiest is a system oriented around the actions of the player.  We keep a 
variable called Time and we increase it by some amount whenever the player does 
something.  This amount of increment can depend on the action taken by the
player (picking up something costs one minute, climbing a mountain takes 100).
The problem with this design is that it does not easily allow other characters
to pursue their own activities.
	Another scheme is to go real time.  The clock just ticks away, and if 
you don't keep moving, well, that's your tough luck.  This is the standard
scheme used in all arcade games, and can be used in many others.  It puts time
pressure on the player, which is good in some situations, but not this one.
	The scheme that I came up is similar to the first with some important
modifications.  Time stays still while you're making up your mind, but as soon
as you decide to execute an action, the program figures how long your action 
will take, sets that time aside in a variable, and then begins incrementing the
clock.  At each increment, it checks each character's execution-time variable
to see if it's time to execute that character's next action.  If the time
has arrived, it goes off and executes the action; if not, it proceeds with
its checking.  Obviously, it takes very little computer time to zip through
a simple loop checking values, so the computer really spends most of its time
executing the character's moves.  And when the human player's move is
executed, the program sits down and waits for the human to enter his next 
move.
	I'm sure that some of the people reading this will find this discussion
quite pedestrian.  Sorry.  I just felt like yakking about mindless details.
.
